with intermittent (predictable and un- 
known) connectivity, large and/or vari- 
able delays, and high bit error rates. To 
provide its services over existing domain 
specific protocols, the DTN protocols 
reside at the application layer of the 
TCP/IP stack, forming a store-and-for- 
ward overlay network. The key capabili- 
ties of the Bundle Protocol include cus- 
tody-based reliability, the ability to cope 
with intermittent connectivity, the abil- 
ity to take advantage of scheduled and 
opportunistic connectivity, and late 
binding of names to addresses. 

Internet standards are published in 
Request For Comments (RFCs), and 
the Bundle Protocol and LTP are de- 
scribed in RFC 5050 and RFC 5326, re- 
spectively. BP provides the store-carry- 
forward, custody transfer and naming 
capabilities of the DTN, while LTP was 
specifically developed for long-delay 
links. LTP allows for “red” and “green” 
data portions in a single session, where 
the red data portion uses retransmis- 
sion and the green data portion does 
not. Unlike common Internet retrans- 
mission protocols, LTP adds the ability 
to suspend and resume timers when the 
link’s status changes. On occasion, the 
models are extended to include non- 
standard experimental features for vali- 
dating project-specific performance or 
behavioral requirements. For instance, 
unlike standard simulation models, the 
BP model supports external traffic in- 
jection, which was used to verify correct 
behavior of the SharedNet middleware 
over DTN protocols and described at 
the SMC-IT 2006 conference (Second 
International Conference On Space 
Mission Challenges For Information 
Technology). The MACHETE LTP 
model supports all standard functions 
of LTP along with an optional priority- 
aware queuing system to prevent lower 
priority from blocking higher-priority 
traffic arriving later. 

Furthermore, MACHETE contains 
Consultative Committee for Space Data 
Systems (CCSDS) protocol standards, 
such as Proximity-1, Advanced Orbiting 
Systems (AOS), Packet Telemetry/ 
Telecommand, Space Communications 
Protocol Specification (SCPS), and the 
CCSDS File Delivery Protocol (CFDP). 
So, with the addition of DTN protocol li- 
braries interplanetary network, engi- 
neers at JPL can characterize future 
space network performance trade-offs. 

This work was done by John S. Segui, Esther 
H. Jennings, and Jay L. Gao of Caltech for 
NASA’s Jet Propulsion Laboratory. For more 
information, contact iaoffice@jpl. nasa.gov. 


This software is available for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@caltech. edu. Refer to NPO-4341 0. 


A Contact Graph Routing 

Contact Graph Routing (CGR) is a dy- 
namic routing system that computes 
routes through a time-varying topology 
of scheduled communication contacts 
in a network based on the DTN (Delay- 
Tolerant Networking) architecture. It is 
designed to enable dynamic selection of 
data transmission routes in a space net- 
work based on DTN. This dynamic re- 
sponsiveness in route computation 
should be significantly more effective 
and less expensive than static routing, 
increasing total data return while at the 
same time reducing mission operations 
cost and risk. 

The basic strategy of CGR is to take 
advantage of the fact that, since flight 
mission communication operations are 
planned in detail, the communication 
routes between any pair of “bundle 
agents” in a population of nodes that 
have all been informed of one another’s 
plans can be inferred from those plans 
rather than discovered via dialogue 
(which is impractical over long one-way- 
light-time space links). Messages that 
convey this planning information are 
used to construct “contact graphs” 
(time-varying models of network con- 
nectivity) from which CGR automatically 
computes efficient routes for bundles. 
Automatic route selection increases the 
flexibility and resilience of the space net- 
work, simplifying cross-support and re- 
ducing mission management costs. 

Note that there are no “routing tables” 
in Contact Graph Routing. The best 
route for a bundle destined for a given 
node may routinely be different from the 
best route for a different bundle destined 
for the same node, depending on bundle 
priority, bundle expiration time, and 
changes in the current lengths of trans- 
mission queues for neighboring nodes; 
routes must be computed individually for 
each bundle, from the Bundle Protocol 
agent’s current network connectivity 
model for the bundle’s destination node 
(the contact graph) . Clearly this places a 
premium on optimizing the implementa- 
tion of the route computation algorithm. 
The scalability of CGR to very large net- 
works remains a research topic. 

The information carried by CGR con- 
tact plan messages is useful not only for 
dynamic route computation, but also for 
the implementation of rate control, con- 


gestion forecasting, transmission epi- 
sode initiation and termination, timeout 
interval computation, and retransmis- 
sion timer suspension and resumption. 

This work was done by Scott C. Burleigh of 
Caltech for NASA’s Jet Propulsion Laboratory. 
Further information is contained in a TSP 
(see page 1 ). 

This software is available, for commercial li- 
censing. Please contact Daniel Broderick of 
the California Institute of Technology at 
danielb@ccdtech.edu. Refer to NPO-45488. 


Parallel Eclipse Project 
Checkout 

Parallel Eclipse Project Checkout 
(PEPC) is a program written to leverage 
parallelism and to automate the check- 
out process of plug-ins created in Eclipse 
RCP (Rich Client Platform). Eclipse 
plug-ins can be aggregated in a “feature 
project.” This innovation digests a fea- 
ture description (xml file) and automat- 
ically checks out all of the plug-ins listed 
in the feature. This resolves the issue of 
manually checking out each plug-in re- 
quired to work on the project. To mini- 
mize the amount of time necessary to 
checkout the plug-ins, this program 
makes the plug-in checkouts parallel. 
After parsing the feature, a request to 
checkout for each plug-in in the feature 
has been inserted. These requests are 
handled by a thread pool with a config- 
urable number of threads. By checking 
out the plug-ins in parallel, the checkout 
process is streamlined before getting 
started on the project. 

For instance, projects that took 30 
minutes to checkout now take less than 
5 minutes. The effect is especially clear 
on a Mac, which has a network monitor 
displaying the bandwidth use. When 
running the client from a developer’s 
home, the checkout process now satu- 
rates the bandwidth in order to get all 
the plug-ins checked out as fast as possi- 
ble. For comparison, a checkout process 
that ranged from 8-200 Kbps from a de- 
veloper’s home is now able to saturate a 
pipe of 1.3 Mbps, resulting in signifi- 
cantly faster checkouts. 

Eclipse IDE (integrated develop- 
ment environment) tries to build a 
project as soon as it is downloaded. As 
part of another optimization, this in- 
novation programmatically tells 
Eclipse to stop building while check- 
outs are happening, which dramati- 
cally reduces lock contention and en- 
ables plug-ins to continue 
downloading until all of them finish. 
Furthermore, the software re-enables 
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